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Abstract 

In  this  paper  we  present  a  formal  language  for  specify¬ 
ing  and  reasoning  about  cryptographic  protocol  require¬ 
ments.  We  give  examples  of  simple  sets  of  requirements 
in  that  language.  We  look  at  two  versions  of  a  proto¬ 
col  that  might  meet  those  requirements  and  show  how 
to  specify  them  in  the  language  of  the  NRL  Protocol 
Analyzer.  [Mea91]  [Mea92]  We  also  show  how  to  map 
one  of  our  sets  of  formal  requirements  to  the  language 
of  the  NRL  Protocol  Analyzer  and  use  the  Analyzer  to 
show  that  one  version  of  the  protocol  meets  those  re¬ 
quirements.  In  other  words,  we  use  the  Analyzer  as  a 
model  checker  to  assess  the  validity  of  the  formulae  that 
make  up  the  requirements. 

Introduction 

The  past  few  years  have  seen  a  proliferation  of  formal 
techniques  for  the  specification  and  analysis  of  crypto¬ 
graphic  protocols.  That  these  techniques  can  be  use¬ 
ful  has  been  shown  by  the  fact  that  several  (includ¬ 
ing  BAN  logic  [BAN89],  the  NRL  Protocol  Analyzer 
Mea91]  [Mea92],  and  the  Stubblebine-Gligor  model 
SG92])  have  been  used  to  find  flaws  in  open  literature 
protocols  that  were  previously  believed  to  have  been  se¬ 
cure.  Thus  the  use  of  formal  methods  for  the  analysis  of 
cryptographic  protocols  has  begun  to  attract  attention 
as  a  promising  way  of  guaranteeing  their  correctness. 

Less  attention,  however,  has  been  paid  to  the  question 
of  what  exactly  constitutes  the  correctness  of  a  cryp¬ 
tographic  protocol.  Yet,  we  see  that  what  constitutes 
correctness  can  vary  widely  with  the  application.  In  a 
key  distribution  protocol  guarantee  of  secrecy  and  guar¬ 
antee  against  replay  attacks  and  impersonation  are  of 
the  most  importance.  For  a  protocol  used  to  guarantee 
the  security  of  banking  deposits,  secrecy  may  or  may 
not  be  important,  although  guarantee  against  replay 
attacks  and  impersonation  definitely  will  be.  Guaran¬ 
tee  of  timeliness  may  also  be  important,  as  well  as  the 
guarantee  that  messages  are  processed  in  the  order  that 
they  are  sent.  (For  example,  a  malicious  intruder  could 
cause  somebody  to  overdraw  his  account  by  causing  a 
deposit  message  and  a  withdrawal  message  to  processed 
out  of  order.)  For  a  protocol  used  to  distribute  rights 
by  proxy,  not  only  is  it  necessary  to  guarantee  against 
impersonation,  but  also  to  guarantee  the  entire  pedigree 


of  a  message. 

Protocols  may  also  differ  in  the  amount  of  trust  that 
is  placed  in  each  individual.  For  example,  Burrows, 
Abadi,  and  Needham,  in  their  logic  of  authentication, 
make  the  assumption  that  the  parties  trying  to  authenti¬ 
cate  each  other  are  honest  and  will  follow  the  rules  of  the 
protocol.1  For  other  protocols,  this  may  not  necessar¬ 
ily  be  the  case.  In  the  Burns-Mitchell  resource  sharing 
protocol  [BM90],  it  is  assumed  that  the  party  attempt¬ 
ing  to  obtain  the  resource  may  be  trying  to  cheat  the 
resource  supplier  into  giving  him  a  resource  that  he  has 
not  paid  for  at  the  same  time  he  is  trying  to  guarantee 
the  the  resource  supplier  is  not  cheating  him.  In  a  vot¬ 
ing  protocol,  we  make  the  assumption  that  individuals 
may  try  to  find  out  other  individuals’  votes,  that  they 
may  try  to  cast  their  votes  more  than  once,  and  that 
they  may  be  willing  to  divulge  their  votes  to  a  small 
group  of  individuals  if  this  will  help  them  subvert  the 
goals  of  the  protocol. 

Even  when  we  restrict  ourselves  to  the  analysis  of  key 
distribution  protocols,  it  is  not  always  clear  what  con¬ 
stitutes  the  appropriate  requirements.  For  example,  in 
[BAN90],  Burrows,  Abadi,  and  Needham  describe  the 
various  orders  of  belief  that  a  protocol  can  achieve,  but 
make  no  recommendations.  For  example,  a  protocol 
may  achieve  first  order  belief,  in  which  A  believes  that 
K  is  a  good  key  for  communication  with  B,  and  vice 
versa,  but  neither  has  any  belief  about  the  beliefs  of  the 
other,  or  it  may  achieve  second  order  belief,  in  which 
not  only  does  each  believe  in  the  key,  but  each  believes 
the  other  believes  in  the  key,  or  it  may  achieve  some 
yet  higher  order  of  belief.  In  [Syv91]  Syverson  discusses 
the  various  orders  of  belief  and  where  each  would  be 
appropriate. 

Confusion  and  vagueness  about  requirements  and  as¬ 
sumptions  has  also  contributed  to  much  of  the  con¬ 
troversy  about  the  various  techniques.  For  example, 
in  [Nes90],  Nessett  points  out  an  alleged  flaw  in  the 
Burrows- Abadi-Needham  logic  by  using  it  to  prove  that 
a  protocol  in  which  keys  are  distributed  in  an  obviously 
unsafe  way  is  secure.  The  response  of  Burrows,  Abadi, 
and  Needham  [BAN90]  was  that  in  their  logic  they  make 
the  assumption  that  principals  do  not  divulge  their  keys; 

1  Honesty  assumptions  are  relaxed  in  the  version  of  BAN  pre¬ 
sented  in  [AT91]. 
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since  in  this  protocol  the  principals  do  divulge  their 
keys,  it  does  not  satisfy  the  original  assumption.  But 
one  can  also  argue  that  the  use  of  an  unsafe  key  distri¬ 
bution  method  is  not  the  same  as  knowingly  divulging 
your  key. 

The  degree  to  which  requirements  and  assumptions  can 
vary,  and  the  controversy  that  can  be  caused  by  a  lack 
of  precise  understanding  of  what  the  requirements  are, 
suggests  that  we  need  to  pay  more  attention  to  under¬ 
standing  and  stating  them  in  a  precise  way.  Once  we 
have  a  clear  and  precise  statement  of  what  the  goals  and 
assumptions  of  a  protocol  are,  we  can  attempt  to  prove 
it  satisfies  these  goals  with  a  high  degree  of  confidence 
that  we  know  what  we  are  about. 

In  this  paper  we  attempt  to  make  it  easier  to  state 
and  reason  about  requirements  in  a  precise  manner  by 
providing  a  requirements  specification  language  for  the 
NRL  Protocol  Analyzer.  The  NRL  Protocol  Analyzer 
has  the  advantage  that  it  is  tied  to  no  particular  set  of 
assumptions  about  the  kind  of  protocol  it  is  used  to  ver¬ 
ify.  The  specifier  of  a  protocol  can  use  it  to  prove  that 
an  insecure  state  is  not  reachable,  or  that  an  insecure 
sequence  of  events  cannot  occur;  it  is  up  to  the  specifier 
to  decide  what  these  states  and  sequences  are.  How¬ 
ever,  until  now  the  user  of  the  Analyzer  had  to  specify 
the  undesired  states  and  sequences  in  terms  of  the  pro¬ 
tocol  specification  itself.  Thus  the  requirements  had  to 
be  rewritten  for  each  protocol  specification,  even  when 
the  aims  of  the  protocols  were  identical.  With  the  re¬ 
quirements  specification  language,  it  is  possible  to  spec¬ 
ify  a  set  of  requirements  for  a  class  of  protocols,  and 
then  map  them  to  a  particular  instantiation.  It  is  also 
possible  to  reason  about  the  requirements  in  isolation 
without  concerning  ourselves  with  particular  protocol 
instantiations. 

The  remainder  of  this  paper  is  organized  as  follows.  In 
section  1  we  present  the  requirements  language  and  give 
the  interpretation  of  the  language  in  the  model  of  com¬ 
putation  used  by  the  Analyzer.  We  also  give  motivat¬ 
ing  examples  of  requirements  of  a  simple  authentication 
protocol.  In  section  2  we  describe  the  NRL  Protocol 
Analyzer  and  give  the  specification  of  the  authentica¬ 
tion  protocol  in  the  language  used  by  the  Analyzer.  We 
then  map  the  requirements  specified  in  section  1  to  the 
specification  via  responses  to  Analyzer  queries.  In  sec¬ 
tion  3  we  present  our  conclusions. 


1  The  Language 

In  this  section  we  set  out  our  formal  requirements  lan¬ 
guage.  In  general,  our  syntax  is  based  on  that  of  tempo¬ 
ral  logic  (cf.  [Gol92]  or  [vB91])  and  in  particular  was  mo¬ 
tivated  by  the  language  of  [Lam90]  and  [Aba90];  how¬ 
ever,  the  intended  meaning  of  the  syntax  is  somewhat 
different  than  in  those  works.  We  begin  with  a  simple 
example  of  the  type  of  things  we  would  like  to  express 
in  our  language.  Then  we  give  the  general  lingusitic 
constructs  and  finally  the  interpretation  thereof  in  the 
model  of  computation. 


1.1  An  Example 

In  order  to  make  clearer  the  abstract  constructs  we  de¬ 
scribe  in  this  paper  we  set  out  some  specific  protocols  as 
examples.  We  will  return  to  these  protocols  throughout 
the  paper  to  illustrate  the  formalisms  and  techniques 
described  herein.  The  protocols  we  present  are  variants 
on  an  ISO  draft  version  of  a  two  pass  one-sided  message 
authentication  protocol.  [IS091]  That  is,  using  two 
messages  this  protocol  is  intended  to  authenticate  to  one 
principal,  B,  that  a  message  is  current  and  from  prin¬ 
cipal  A.  To  make  it  slightly  more  interesting  we  have 
modified  the  original  ISO  protocol  so  that  the  confiden¬ 
tiality  of  the  message  is  protected  as  well.  We  present 
two  versions  of  the  protocol,  one  using  shared  keys  and 
one  using  public  keys.  The  original  ISO  protocol  uses 
only  public  keys  and  does  not  protect  the  confidentiality 
of  the  message. 

Example  1.1  Shared  Key  Version 
B  sends  to  A:  B,  Ni, 

A  sends  to  B:  B,  Na,  Ni,,  {Aa,  Aj,  Message}ifab 

Here  Aj  is  a  nonce,  a  random  number,  generated  by 
B,  Na  is  a  nonce  generated  by  A,  and  Kaj,  is  a  key 
shared  between  A  and  B.  The  last  Held  of  the  second 
message  indicates  that  Na,  Aj  and  A’ s  message  have 
been  encrypted  together  using  Kat.  □ 

Example  1.2  Public  Key  Version 

B  sends  to  A:  B,  Aj 

A  sends  to  B:  B,  Na,  Nb,  {{Aa,  Nb,  Message}K-i 

Here  Na  and  Aj  are  nonces  as  before,  K~x  is  A’s  private 
key,  and  Kj,  is  B’ s  public  key.  Thus,  the  last  field  of  the 
second  message  indicates  that  Na,  Aj,  and  A’s  message 
have  been  signed  together  using  A’s  private  key  and 
then  encrypted  using  B’ s  public  key.  □ 

1.2  Requirements 

One  of  the  disadvantages  of  currently  available  logical 
languages  for  cryptographic  protocol  analysis  is  that  for 
the  most  part  each  protocol  has  its  own  specification. 
Our  approach  goes  some  way  towards  a  remedy  by  al¬ 
lowing  a  single  set  of  requirements  to  specify  a  whole 
class  of  protocols.  This  has  the  advantage  that  a  proto¬ 
col  analyst  can  largely  identify  the  goals  of  any  protocol 
in  this  class  with  that  one  specification,  which  seems  to 
be  a  fairly  intuitive  way  to  view  things.  For  instance 
one  might  want  evaluate  a  protocol  for  two  party  ses¬ 
sion  key  distribution  using  ordinary  public  or  shared  key 
cryptography.  While  many  of  these  protocols  have  spe¬ 
cial  features  and  requirements,  there  are  a  number  of 
requirements  they  all  share — for  example,  that  the  dis¬ 
tributed  key  be  known  only  to  the  two  principals  and 
the  server  if  there  is  one.  We  can  express  in  our  lan¬ 
guage  general  requirements  for  protocols  for  distributing 
session  keys  to  two  parties  via  a  server.  This  specifica¬ 
tion  should  also  satisfy  protocols  with  no  server,  i.e. , 


where  one  of  the  participants  is  the  server.  It  should 
also  work  for  interdomain  communications.  Although 
there  are  undoubtedly  further  requirements  to  be  spec¬ 
ified  for  servers  from  different  domains  to  authenticate 
each  other,  that  process  should  not  affect  the  require¬ 
ments  for  the  two  end  parties  in  relation  to  whoever 
produces  the  key.  While  this  is  probably  the  type  of 
protocol  of  broadest  use  and  interest,  for  purposes  of  il¬ 
lustrating  our  requirements  language  and  analysis  tech¬ 
nique  it  is  clearer  to  stick  to  a  simpler  example  than 
this. 

What  are  the  general  security  requirements  for  the  type 
of  authentication  protocol  given  by  our  examples  above? 
That  is,  if  B  were  to  accept  the  message  from  A,  what 
need  hold  to  preclude  security  violations?  First  of  all, 
we  need  to  make  the  distinction  between  an  honest  and 
a  dishonest  A.  If  A  is  dishonest,  then  we  assume  that  A 
may  violate  any  or  all  of  the  rules  of  the  protocol,  and 
is  in  collusion  with  the  hostile  intruder  who  we  assume 
is  trying  to  subvert  the  goals  of  the  protocol.  This  does 
not  mean  that  we  may  not  put  any  requirements  upon 
interchanges  involving  a  dishonest  A,  but  if  we  do,  the 
requirements  may  be  different  than  the  requirements  we 
put  upon  an  honest  A. 

Now  we  consider  a  set  of  requirements.  First,  the  pen- 
etrator  (denoted  in  our  requirements  language  by  P), 
must  not  learn  the  content  of  the  message.  Second,  A 
must  have  actually  sent  the  message,  and  she  must  have 
done  so  after  B’s  ‘query’.  We  must  assume  that  A  is 
honest,  since  if  A  is  dishonest  we  assume  that  the  pene- 
trator  can  learn  the  message  as  soon  as  A  creates  it  and 
that  A  can  send  a  message  at  any  time. 

In  our  formal  language  we  express  the  requirements  by 
indicating  the  temporal  order  in  which  these  actions 
must  occur.  We  use  £— *■’  to  represent  the  standard  condi¬ 
tional,  ‘A’  to  represent  conjunction,  and  to  represent 
a  temporal  operator  meaning  at  some  point  in  the  past. 
We  assume  that  principals  can  keep  track  of  rounds  of 
protocols  from  their  perspective  via  local  round  num¬ 
bers,  where  a  round  number  local  to  a  principal  iden¬ 
tifies  all  actions  pertaining  to  a  single  session  as  far  as 
that  principal  is  concerned.  Thus  accept(B,  A,  Mes,  N) 
means  that  B  accepts  the  message  Mes  as  from  A  during 
B’s  local  round  N ,  learn(P,  Mes))  means  the  penetra- 
tor  P  learns  the  word  Mes,  send(A,  B,  (Query,  Mes)) 
means  that  A  sends  B  Mes  in  response  to  query 
Query,  and  request (B ,  A,  Query ,  N))  means  that  B 
sends  query  Query  to  A.  Precise  descriptions  of  the 
meaning  of  the  syntactic  expressions  will  be  given  later 
in  the  paper.  For  now  we  are  simply  trying  to  present 
realistic  but  also  fairly  intuitive  examples  of  formulae  in 
the  language.  We  can  then  represent  our  requirements 
as  follows: 

Requirements  1.3 

•  -i(^accept(B,  A,  Mes)  A  ^learn (P,  Mes)) 

•  accept(B,  A,  Mes,  N)  — >■ 

^(send(A,  B,  (Query,  Mes))  A 

^request(B,  A,  Query,  N)) 


□ 

In  order  to  be  secure  a  protocol  must  satisfy  the  con¬ 
junction  of  the  requirements.  They  must  both  hold; 
although,  it  helps  keep  things  clear  if  we  list  them  sepa¬ 
rately.  It  will  also  facilitate  application  of  the  NRL  Pro¬ 
tocol  Analyzer.  Note  that  the  request  must  come  from 
B  even  though  the  protocols  we  are  looking  at  provide 
no  authentication  of  the  first  message.  This  may  seem 
odd  since  A  thus  has  no  way  of  being  sure  who  sent 
the  request.  Nonetheless,  the  request  must  come  from 
B  even  if  A  does  not  know  this:  B  will  know  whether 
or  not  the  message  is  in  response  to  his  request  when 
he  decrypts  it  and  checks  the  nonce.  If  the  message  is 
in  response  to  anyone  else’s  request,  the  nonce  will  not 
correspond  to  the  one  B  used,  and  B  should  not  accept 
the  message  as  appropriate. 

This  also  indicates  that  we  have  here  just  one  of  many 
possible  sets  of  requirements.  Perhaps  it  is  not  neces¬ 
sary  that  A  sent  the  message  in  response  to  B’s  query, 
only  after  B’s  query.  For  example,  B  may  be  requesting 
the  value  of  some  sensor,  and  it  may  only  be  important 
that  the  sensor  value  be  from  after  B’s  request  rather 
than  a  response  specifically  to  it.  We  can  capture  this 
with  the  following  simplification  of  the  first  set  of  re¬ 
quirements. 

Requirements  1.4 

•  -i(^accept(B,  A,  Mes)  A  ^learn(T’,  Mes)) 

•  accept(B,  A,  Mes,  N)  — >■ 

^(send(A,  B,  Mes)  A  ^request(B,  A,  TV)) 

□ 

Alternatively,  it  might  only  be  important  that  the  mes¬ 
sage  from  A  be  recent.  We  may  require  that  the  message 
be  recent  by  B’s  judgement  (so  that  B  will  not  accept 
a  message  that  arrives  too  late  after  he  requested  it), 
or  recent  by  A’s  judgement  (so  that  B  will  not  accept  a 
message  that  arrives  too  late  after  A  sent  it),  or  both. 
We  here  represent  the  case  in  which  both  are  required. 

Requirements  1.5 

•  -i(^accept(B,  A,  Mes)  A  ^learn(T’,  Mes)) 

•  accept(B,  A,  Mes,  N)  — >■ 

^(send(A,  B,  Mes)  A  ^request(B,  A,  TV)) 

•  accept(B,  A,  Mes,  N)  — >■ 

^(send(A,  B,  Mes)  A  -i(^time_out(B,  Nj)  A 
-i(^time_out(A,  Mes)) 

□ 

Another  possibility  is  that  we  need  to  guard  against 
replay  in  the  sense  that  if  B  accepts  a  message  as 


from  an  honest  A,  then  it  must  never  have  been  ac¬ 
cepted  previously  by  another  honest  principal.  Or,  we 
can  make  the  stronger  requirement  that  if  B  accepts 
a  message  as  from  A,  then  it  never  was  accepted  pre¬ 
viously,  whether  or  not  A  was  honest  or  dishonest. 
In  this  case,  since  we  are  dealing  with  both  honest 
and  dishonest  principals  it  is  helpful  to  make  a  nota- 
tional  distinction  between  them.  We  designate  an  hon¬ 
est  user  A  by  user( A,  honest),  a  dishonest  user  A  as 
user(A,  dishonest),  and  a  user  who  may  be  honest  or 
dishonest  as  user(A,  Y),  where  Y  is  a  variable  that  may 
take  on  the  value  “ honest ”  or  “dishonest” .  The  case 
in  which  we  require  that  if  an  honest  B  accepts  a  mes¬ 
sage  as  coming  from  an  honest  A,  then  it  was  never 
accepted  previously  by  any  other  honest  user,  would  be 
represented  as  follows: 

Requirements  1.6 

•  -i^accept(aser(5,  honest),  user(A,  honest),  Mes) 

V  -i^learn(.P,  Mes)) 

•  accept(aser(5,  honest),  user(A,  honest),  Mes,  N) 
—>■  ^(send(aser(j4,  honest),  user(B,  honest),  Mes) 

A  ^request (user(B,  honest),  user(A,  honest),  N)) 

•  accept(aser(5,  honest),  user(A,  honest),  Mes)  —>■ 

-^accept (user(C,  honest),  user(D,  Y),  Mes) 

□ 

Note  that  our  requirement  says  that  the  message  must 
not  have  been  previously  accepted  by  any  honest  user 
as  coming  from  anybody,  whether  honest  or  dishonest. 
Note  also  that  it  does  not  matter  whether  the  proto¬ 
col  uses  public  or  shared  key  cryptography.  Nor  do  we 
specifically  require  that  nonces  be  used.  For  some  of  the 
above  sets  of  requirements  it  may  or  may  not  be  more 
natural  to  have  protocols  using  timestamps  or  sequence 
numbers.  These  points  should  provide  some  indication 
of  the  generality  with  which  requirements  can  be  stated 
even  when  being  formal.  We  will  return  to  look  at  the 
last  of  these  sets  of  sample  requirements  below,  after  we 
have  precisely  set  out  the  language  and  its  interpreta¬ 
tion. 

1.3  Syntax 

Our  language  contains  a  denumerable  collection  of  con¬ 
stant  singular  terms,  typically  represented  by  letters 
from  the  beginning  of  the  alphabet.  We  also  have  a 
denumerable  collection  of  variable  terms,  typically  rep¬ 
resented  by  letters  from  the  end  of  the  alphabet.  We 
also  have,  for  each  n  >  1,  n-ary  function  letters  tak¬ 
ing  terms  of  either  type  as  arguments  and  allowing  us 
to  build  up  functional  terms  in  the  usual  recursive  fash¬ 
ion.  (We  will  always  indicate  whether  a  term  is  constant 
or  variable  if  there  is  any  potential  for  confusion.)  We 
have  a  denumerable  collection  of  n-ary  action  symbols 
for  each  arity  n  >  1.  These  will  be  written  as  words  in 
typewriter  scrypt  (e.g.,  accept).  The  first  argument  of 
an  action  symbol  is  reserved  for  a  term  representing  the 
agent  of  the  action  in  question. 


An  atomic  formula  consists  of  an  n-ary  action  symbol, 
e.g.,  ‘act’  followed  by  an  n-tuple  of  terms.  We  have  the 
usual  logical  connectives:  A,  V,  — and  <->,  and  also 

one  temporal  operator:  $>.  Complex  formulae  are  built 
up  from  atomic  formulae  in  the  usual  recursive  fashion. 
Since  we  have  already  seen  examples  of  formulae,  we 
proceed  directly  to  their  interpretation.  (Note  that  this 
is  only  a  formal  language,  not  a  logic;  hence  there  are 
no  axioms  or  inference  rules.) 

1.4  Interpretations 

The  key  notion  to  understand  is  that  of  an  action.  For 
us  actions  are  transitions  from  one  state  to  another.  We 
represent  these  semantically  by  ordered  pairs  of  the  form 
(s,  s'),  where  ‘s’  represents  the  state  prior  to  the  action 
and  ‘s'’  represents  the  state  subsequent  to  the  action. 
The  precise  way  this  works  is  given  in  the  definition  of 
an  interpretation. 

Definition  1.7  A  state  space  is  a  non-empty  set  S,  and 
each  s  £  S  is  a  state.  We  represent  time  digitally  us¬ 
ing  the  integers.  A  trace  is  a  sequence  a  of  elements 
of  S  that  is  infinite  in  both  directions,  for  example, 

.  .  . ,  s8_i,  Si,  s8_|_i,  .  .  ..  We  can  thus  equate  a  trace  with 
a  function  from  times  to  states.  If  s  is  the  value  of  cr(t), 
we  will  generally  adopt  the  notational  convenience  of 
representing  this  by  ‘st’.  Let  a  and  [3  be  formulae.  An 
interpretation  is  a  function  I  from  atomic  formulae  of 
the  language  to  subsets  of  S  x  S,  i.e. ,  1(a)  C  S  x  S  for 
any  atomic  formula  a. 

A  model  is  an  ordered  4-tuple,  ( S ,  I,  a,t)  such  that  S  is 
a  state  space,  I  is  an  interpretation,  a  is  a  trace,  and 
t  is  a  time.  The  satisfaction  relation,  \=,  is  a  relation 
between  models  and  formulae.  It  is  our  way  of  speci¬ 
fying  which  formuale  are  true:  given  a  formula  a  and 
a  model  ( S,I,cr,t ),  c(S,I,cr,t)  |=  a’  means  that  a  is 
true  at  ( S,I,cr,t ).  It  is  defined  as  the  smallest  relation 
between  models  and  formulae  satisfying  the  following: 


( S ,  I,  <T,t)  1=  a 

=  df 

( St ,  st+i)  £  I(a) 

( S ,  I,  (T,t)  1=  nft 

=  df 

(■ S,I,a,t )  a 

( S ,  I,a,t)  \=  a  A  /3 

=  df 

( S ,  I,  cr,t )  \=  a  and 

(S,I,cr,t)  \=  j3 

( S ,  I,a,t)  \=  a  V  (3 

=  df 

( S ,  I,  cr,t)  \=  a  or 

(S,I,a,t)  \=  (3 

( S ,  I,a,t)  \=  a  —>■  j3 

=  df 

( S ,  I,  cr,t)  a  or 

(S,I,a,t)  1=  (3 

( S ,  I,(T,t) 

=  df 

( S ,  I,  a,t)  |=  a  —>  [3  and 
( S ,  I,a,t)  \=  (3  — >■  a 

(S,I,a,t)  \=  <$a 

=  df 

( S ,  I,  cr,  t')  |=  a  for  some  t 
such  that  t'  <  t 

Given  a  class  of  models  k,  we  say  that  a  formula  a  has  a 
K-model  or  is  K-satisfiable  if  there  exists  ( S,I,cr,t )  £  k 
such  that  ( S,I,cr,t )  |=  a.  We  say  that  a  is  K-vahd  if 


( S,I,a,t }  |=  a  for  all  ( S,I,a,t }  E  k.  This  is  written 
|=K  a.  When  k  is  clear  from  context  or  when  k  is  the 
class  of  all  models  we  drop  explicit  reference  to  it  in 
these  expressions.  □ 

1.5  Models  of  Computation 

We  will  not  be  looking  at  the  class  of  all  models  for 
purposes  of  protocol  analysis.  We  now  set  out  the  class 
we  will  be  using.  We  begin  by  describing  some  of  the 
technical  machinery  we  need.  Our  description  of  states 
and  actions  is  motivated  primarily  by  the  formalisms 
operated  on  by  the  NRL  Protocol  Analyzer.  (Recall 
that  our  goal  is  to  use  the  Analyzer  as  a  model  checker 
to  see  if  a  given  protocol  meets  a  set  of  requirements.) 

The  model  used  by  the  Protocol  Analyzer  is  an  exten¬ 
sion  of  the  Dolev-Yao  model  [DY83].  We  assume  that 
the  participants  in  the  protocol  are  communicating  in  a 
network  under  the  control  of  a  hostile  intruder  who  may 
also  have  access  to  the  network  as  a  legitimate  user  or 
users.  The  intruder  has  the  ability  to  read  all  message 
traffic,  destroy  and  alter  messages,  and  create  his  own 
messages.  Since  all  messages  pass  through  the  intruder’s 
domain,  any  message  that  an  honest  participant  sees 
can  be  assumed  to  originate  from  the  intruder.  Thus  a 
protocol  rule  describes,  not  how  one  participant  sends 
a  message  in  response  to  another,  but  how  the  intruder 
manipulates  the  system  to  produce  messages  by  causing 
principals  to  receive  certain  other  messages. 

As  in  Dolev-Yao,  the  words  generated  in  the  protocol 
obey  a  set  of  reduction  rules  (that  is,  rules  for  reducing 
words  to  simpler  words),  so  we  can  think  of  the  proto¬ 
col  as  a  machine  by  which  the  intruder  produces  words 
in  the  term-rewriting  system.  Also,  as  in  Dolev-Yao, 
we  make  very  strong  assumptions  about  the  knowledge 
gained  when  an  intruder  observes  a  message.  We  assume 
that  the  intruder  learns  the  complete  significance  of  each 
message  at  the  moment  that  it  is  observed.  Thus,  if  the 
intruder  sees  a  string  of  bits  that  is  the  result  of  encrypt¬ 
ing  a  message  from  A  to  B  with  a  session  key  belonging 
to  A  and  B,  he  knows  that  is  what  it  is,  although  he 
will  not  know  either  the  message  or  the  key  if  he  has 
not  observed  them. 

A  specification  in  the  Protocol  Analyzer  describes  how 
one  moves  from  one  state  to  another  via  honest  partici¬ 
pants  sending  data,  honest  participants  receiving  data, 
honest  participants  manipulating  stored  data,  and  the 
intruder’s  manipulation  of  data  sent  by  the  honest  par¬ 
ticipants.  Dishonest  participants  are  identified  with  the 
intruder,  and  so  are  not  modeled  separately.  The  send¬ 
ing  and  receipt  of  messages  by  the  intruder  is  not  mod¬ 
eled  separately,  since  it  is  automatically  assumed  that 
any  message  sent  is  received  by  the  intruder,  and  any 
message  received  is  sent  by  the  intruder,  even  if  it  is 
only  passed  on  by  the  intruder  unchanged.  Thus  every 
receipt  of  a  message  by  an  honest  principal  implies  the 
sending  of  a  message  by  the  intruder,  and  every  sending 
of  a  message  by  an  honest  principal  implies  the  receipt 
of  a  message  by  the  intruder. 

Given  this,  we  look  at  the  notion  of  a  state  more  closely. 
One  of  the  primary  components  of  a  state  is  a  learned 


fact.  Each  honest  protocol  participant  possesses  a  set 
of  learned  facts.  Each  learned  fact  is  relevant  to  a  given 
round  of  the  protocol.  A  learned  fact  is  described  using 
an  Ifact  function,  which  has  four  arguments.  The  first 
identifies  the  participant  A  for  whom  it  is  a  learned 
fact.  This  will  give  us  the  agent  of  an  action.  The 
second  identifies  the  round  of  the  protocol  via  a  round 
number  that  is  local  to  the  principal  denoted  by  the 
first  argument.  This  will  allow  each  principal  to  attach 
each  relevant  action  to  a  particular  round  of  a  particular 
protocol.  The  third  indicates  the  nature  of  the  fact. 
Generally  this  will  indicate  the  action  that  the  agent 
is  taking.  The  fourth  gives  the  present  value  of  A’ s 
counter.  In  effect,  this  gives  us  a  local  clock  value.  The 
value  of  the  Ifact  is  either  a  list  of  words  that  make  up 
the  content  of  the  fact,  or  if  the  fact  does  not  have  any 
content,  it  is  “[  ]”,  the  empty  list. 

One  way  we  represent  actions  semantically  is  via 
changes  in  learned  facts;  however,  we  do  not  allow  ar¬ 
bitrary  changes  in  the  value  of  Ifact.  A  nonempty  list 
can  be  the  value  of  Ifact  for  a  given  principal,  round, 
and  action,  at  the  principal’s  local  time  T  only  if  the 
value  of  Ifact  for  that  principal,  round,  and  action,  at 
the  time  immediately  prior  to  T  was  [  ]. 

Thus,  for  example,  suppose  that  A  has  attempted  to 
initiate  a  conversation  with  B  during  local  round  N  at 
time  T.  This  can  be  expressed  by  the  action  (s,  s')  where 
the  difference  between  s  and  s'  is  that  in  s, 

lfact(user(A,  honest),  N,init_conv,T)  =  [] 
and  in  s' , 

lfact(user(A,  honest),  N,init_conv,T+l)  =  [user(B)] 

At  any  time  prior  to  T,  the  value  of  the  Ifact  would  also 

be  [  ]• 

It  is  also  useful  to  allow  certain  actions  to  be  ‘forgotten’. 
This  is  accomplished  by  having  a  transition  in  which  the 
value  of  Ifact  goes  from  a  nonempty  list  to  [  ] . 

Another  component  of  a  state  is  the  intruder’s  knowl¬ 
edge,  represented  as  a  monotonically  nondecreasing 
function  of  time.  It  is  necessary  to  represent  this  in 
a  manner  distinct  from  the  learned  facts  because  the 
Analyzer  represents  the  intruder  in  a  different  way  than 
it  represents  ordinary  principals.  There  are  two  kinds  of 
actions  associated  with  intruder  knowledge  that  we  al¬ 
low.  In  the  first  of  these,  the  intruder  learns  some  word, 
that  is,  a  string  of  symbols.  For  instance,  suppose  that 
A  sends  a  message  W  to  B  at  time  1 1,  and  the  intruder 
intercepts  (and  thus  learns)  W  at  time  t2.  According  to 
what  we  have  set  out  above,  this  can  be  represented  by 
(s,  s'),  where  in  s, 

lfact(user(A),N,send_to_B,T)  =  [] 

and  in  s', 

lfact(user(A),N,send_to_B,T+l)  =  [W] 


Then,  the  intruder  learning  of  this  action  is  given  by 
(s'jS11),  where  the  only  change  from  s'  to  s"  is  that  in 
s"  we  have 

intruderknows(tl)  =  intruderknows(t2)  U  {[W]} 

where  intruderknows(t)  is  the  set  of  words  known  by 
the  intruder  at  the  global  time  t,  and  tl  and  t2  are 
the  global  times  corresponding  to  A’ s  local  times  T  and 
T  +  1,  respectively. 

The  second  way  the  intruder  may  increase  his  knowledge 
is  by  performing  some  available  internal  operations  on 
things  he  already  knows.  In  other  words,  assuming  u>  is 
some  n-ary  operation  of  which  the  intruder  is  capable, 
if  {Wi,  .  .  . ,  W„}  C  intruderknows(f),  then 

intruderknows(t2)  =  intruderknows(tl)  U 
{co(W1,...,Wn)j, 

where  tl  and  t2  are  again  global  times. 

Definition  1.8  The  four  types  of  actions  just  given  will 
be  called  ‘ baste  actions’.  A  basic  model  is  one  in  which, 
for  any  given  trace  a,  one  basic  action  may  occur  per 
unit  time,  and  these  specify  the  only  allowable  differ¬ 
ences  between  a  state  and  its  successor.  □ 

While  basic  models  provide  us  with  a  simple  model  of 
computation  in  which  to  interpret  the  expressions  of  our 
language,  they  are  too  simple  to  be  practical  in  most 
cases,  especially  as  a  basis  for  analysis  using  the  NRL 
Protocol  Analyzer.  What  we  would  like  is  a  model  in 
which  state  transitions  can  be  complex  enough  to  be 
useful  but  simple  enough  to  provide  assurance  that  our 
model  is  a  reasonable  one.  To  this  end  we  introduce 
compressed  models. 

Definition  1.9  A  compressed  model  is  a  model  M  for 
which  there  exists  a  basic  model  M'  satisfying  the  fol¬ 
lowing: 

•  The  state  space  and  interpretation  for  M  and  M' 
is  the  same. 

•  The  trace  a  in  M  is  a  subtrace  of  cr' ,  the  trace  in 

M! 

□ 

In  particular,  this  means  that  for  every  transition 
(st,st_l_i)  in  cr,  there  exists  a  subsequence  of  cr' , 
(it '  (i),  .  .  . ,  it '  (i  +  n)),  such  that  st  =  cr'(i)  and  st+i  = 
cr '  (i  +  n).  Now  that  we  have  the  essentials  of  our  se¬ 
mantics  worked  out,  we  can  look  at  the  satisfaction  of 
the  requirements  that  we  mentioned  above.  We  focus 
on  requirements  1.4  for  example. 

Recall  the  two  formulae  constituting  the  requirements: 

•  -i(^accept(B,  A,  Mes)  A  ^learn (P,  Mes)) 


•  accept(B,  A,  Mes,  N)  — >■ 

^(send(A,  B,  Mes )  A  ^request(B,  A,  TV)) 


We  can  give  a  very  simple  description  of  the  compu¬ 
tational  truth  conditions  of  these  requirements.  For 
example,  ( S,I,cr,t )  \=  accept (B ,  A,  Mes,  N)  iff  in  st 
lfactluserlB),  N,  accept_from_A,  T)  =  [  ]  and  in  st+i 
lfact(user(B),  N,  accept_from_A,  T+l)  =  [Mes].  This 
is  of  course  not  very  revealing.  While  what  constitutes 
a  send  or  receive  action  should  be  immediately  clear, 
an  accept  action  is  somewhat  complex.  Thus,  while 
we  can  present  a  model  with  such  a  simple  interpreta¬ 
tion,  we  need  to  give  a  more  detailed  interpretation  of 
an  accept  action  if  we  are  to  get  any  use  out  of  it. 

It  would  be  hopeless  to  give  general  truth  conditions 
for  an  accept  action.  Fortunately,  at  this  point  we  can 
turn  to  the  protocol  in  question  to  see  what  would  con¬ 
stitute  a  reasonable  interpretation  of  accepting  a  mes¬ 
sage.  Accepting  a  message  is  what  occurs  when  all  the 
relevant  checks  have  been  verified  by  the  accepting  prin¬ 
cipal.  Thus,  for  the  protocol  of  example  1.2  we  would 
have  as  part  of  the  first  state  of  the  accept  action  that 
the  nonce  of  the  second  message  be  verified  as  the  same 
nonce  that  was  sent  in  the  first  message.  There  are  other 
things  to  verify  as  well,  and  different  protocols  gener¬ 
ally  have  different  sets  of  checks  to  verify  as  conditions 
on  an  acceptance  of  a  message.  Of  course  the  atomic 
actions  and  their  interpretations  can  be  quite  different 
when  we  move  to  an  entirely  distinct  class  of  protocols, 
e.g.,  key  distribution  protocols.  The  exact  details  of  this 
will  be  set  out  below  when  we  describe  how  to  specify 
the  protocol  for  the  Analyzer. 

Once  we  have  set  an  interpretation  for  all  of  the  expres¬ 
sions  used  in  the  statement  of  requirements  and  have 
specified  the  protocol  itself,  we  are  in  a  position  to  de¬ 
termine  whether  or  not  the  protocol  meets  the  require¬ 
ments.  Given  a  fixed  state  space  S  and  interpretation 
I,  we  consider  the  class  k  of  all  models  ( S ,  I,  cr,  t)  for 
which  cr  is  a  trace  of  the  protocol  specification.  To  see 
if  the  protocol  meets  the  requirements  we  simply  see  if 
the  formulae  that  constitute  the  requirements  are  valid 
in  k.  Of  course,  while  the  check  is  very  simple  in  theory, 
it  is  rather  difficult  in  practice.  This  is  where  the  NRL 
Protocol  Analyzer  comes  in:  it  helps  us  to  make  the 
determination.  That  is,  to  see  if  the  protocol  meets  the 
requirements  we  present  the  Analyzer  with  the  require¬ 
ments  and  the  interpretation  of  atomic  actions  therein. 
We  then  ask  it  to  determine  if  the  models  in  k  are  a  sub¬ 
class  of  those  that  make  the  requirements  true.  We  will 
show  how  to  do  this  below  for  the  sample  protocol  and 
sample  requirements  presented  above.  The  analysis  is 
primarily  conducted  in  the  language  of  the  Analyzer, 
which  for  us  amounts  to  a  semantic  description  lan¬ 
guage.  Thus,  we  present  a  description  of  the  Analyzer 
and  its  language  before  further  examining  our  sample 
protocol  with  respect  to  our  sample  requirements. 


2  The  NRL  Protocol  Analyzer 

2.1  The  Specification  Language  Used  by 
the  NRL  Protocol  Analyzer 

A  specification  in  the  NRL  Protocol  Analyzer  consists 
of  four  sections.  The  first  section  consists  of  transi¬ 
tion  rules  governing  the  actions  of  honest  principals.  It 
may  also  contain  rules  describing  possible  system  fail¬ 
ures  that  are  not  necessarily  the  result  of  actions  of  the 
intruder,  for  example,  the  compromise  of  a  session  key. 
The  second  section  describes  the  operations  that  are 
available  to  the  honest  principals  and  possibly  to  the 
intruder,  e.g.,  encryption  and  decryption.  The  third 
section  describes  the  atoms  that  are  used  as  the  basic 
building  blocks  of  the  words  in  the  protocol.  The  fourth 
section  describes  the  rewrite  rules  obeyed  by  the  oper¬ 
ations. 

A  transition  rule  has  three  parts.  The  first  part  gives 
the  conditions  that  must  hold  before  the  rule  can  fire. 
These  conditions  describe  the  words  the  intruder  must 
know  (that  is,  the  message  that  must  be  received  by 
the  principal),  the  values  of  the  lfacts  available  to  the 
principal,  and  any  constraints  on  the  lfacts  and  words. 
At  the  moment,  the  syntax  of  the  constraints  on  words 
is  somewhat  restricted;  they  can  only  say  that  words 
must  or  must  not  be  of  a  given  length  or  that  they 
must  or  must  not  be  equal  to  other  words.  The  second 
part  describes  the  conditions  that  hold  after  the  rule 
fires  in  terms  of  words  learned  by  the  intruder  (that  is, 
the  message  sent  by  the  principal)  and  any  new  values 
taken  on  by  lfacts.  Each  time  a  rule  fires,  the  principal’s 
local  time  is  incremented;  this  is  also  recorded  in  the 
preconditions  and  postconditions  of  the  rule.  The  third 
part  of  the  rule  consists  of  an  event  statement.  It  is  used 
to  record  the  bring  of  a  rule  and  is  useful  for  indicating 
what  the  rule  does.  It  is  derived  from  the  first  two  parts 
of  the  rule.  The  event  statement  describes  a  function 
with  four  arguments.  The  first  gives  the  name  of  the 
relevant  principal.  The  second  gives  the  number  of  the 
protocol  round.  The  third  identifies  the  event.  The 
fourth  gives  the  value  of  the  principal’s  counter  after 
the  rule  fire.  The  value  of  the  event  is  a  list  of  words 
relevant  to  the  event. 

An  example  of  a  rule  is  the  following.  Suppose  we  are 
at  the  point  in  the  ISO  protocol  in  which  an  honest 
principal,  user(honest,B),  has  decided  to  request  a  mes¬ 
sage  from  another  principal,  user(A,Y),  and  sends  him 
a  nonce.  This  can  be  modeled  by  the  following  rule: 

If: 

count(user(B, honest) )  =  [M]  , 

If act (user (B , honest) ,I,recwho,M)  = 

[user(A, Y)] , 

not(user(A,Y)  =  user(B, honest) ) , 
then: 

count(user(B, honest) )  =  [s(M)], 
intruderlearns ( [user(B, honest) , 

rand(user(B, honest) ,M)] ) , 

If act (user (B , honest) ,I,recsendsnonce,s(M) )  = 
[rand(user(B, honest) ,M)] , 

EVENT : 

event (user (B , honest ) , I, request edmes sage , s (M) ) 


=  [user(A,Y) , rand (user(B, honest) ,M)]  . 

In  this  rule  the  recwho  lfact  is  used  to  hold  the  name 
of  the  user  user(B, honest)  is  trying  to  talk  too,  and 
the  recsendsnonce  lfact  holds  the  random  nonce  that 
user(B, honest)  sends  to  user(A,Y).  The  event  statement 
going  with  this  rule  is  denoted  by  “requestedmessage” 
and  holds  the  words  used  in  this  rule:  namely,  the  name 
of  user(A,Y)  and  the  nonce. 

The  second  section  of  the  specification  defines  the  oper¬ 
ations  that  can  be  made  by  honest  principals  and  by  the 
intruder.  If  an  operation  can  be  made  by  the  intruder, 
the  Analyzer  translates  it  into  a  transition  rule  similar 
to  the  above,  except  that  the  relevant  principal  is  the 
intruder  instead  of  an  honest  principal,  and  no  lfacts  are 
involved.  An  example  of  a  specification  of  an  operation 
is  the  following,  describing  public  key  encryption: 

f  sdl  :pke  (X,  Y) :  length. (X)  =  1: 

length. (pke(X,Y) )  =  length (Y ): pen. 

The  term  “fsd”  stands  for  “function  symbol  descrip¬ 
tion.”  The  next  term  gives  the  operation  and  the  ar¬ 
guments.  The  third  gives  conditions  on  the  arguments. 
In  this  case,  we  make  the  condition  that  the  key  be  a 
certain  length,  which  in  this  case  we  make  a  default  unit 
length  one.  The  next  term  gives  the  length  of  the  re¬ 
sulting  word,  which  in  this  case  is  the  length  of  Y.  The 
last  Held  is  set  to  “pen”  if  we  are  assuming  that  the 
penetrator  can  perform  the  operation,  and  “nopen”  if 
we  are  assuming  that  he  can’t.  Thus  the  decision  to 
put  “pen”  or  “nopen”  into  the  last  field  may  vary  with 
our  assumptions  about  the  environment  in  which  the 
protocol  is  operating. 

Some  operations  are  built  into  the  system.  These  are: 
concatenation,  taking  the  head  of  a  list,  taking  the  tail 
of  a  list,  and  id_check,  which  is  used  by  an  honest  prin¬ 
cipal  to  determine  whether  or  not  two  words  are  equal. 

The  third  section  describes  the  words  that  make  up  the 
basic  building  blocks.  We  call  these  words  “atoms”.  Ex¬ 
amples  would  be  user  names,  keys,  and  random  num¬ 
bers.  Again,  we  indicate  whether  or  not  the  word  is 
known  to  the  intruder  in  the  last  field  of  an  atom  spec¬ 
ification,  it  is  “known”  if  the  intruder  knows  it  initally, 
and  “notknown”  if  the  intruder  doesn’t  know  it  initially. 

The  last  section  describes  the  rewrite  rules  by  which 
words  reduce  to  simpler  words.  An  example  of  a  rewrite 
rule  would  be  one  which  describes  the  fact  encryption 
with  corresponding  public  and  private  keys  cancel  each 
other  out: 

rrl:  pke(privkey(X) ,pke(pubkey (X) ,Y))  =>  Y. 
rr2 :  pke(pubkey(X) ,pke(privkey (X) ,Y))  =>  Y. 

One  queries  the  Analyzer  by  asking  it  to  find  a  state  that 
consists  of  a  set  of  words  known  by  the  intruder,  a  set  of 
lfacts,  and  a  sequence  of  events  that  must  have  occurred. 
One  can  put  conditions  on  the  words,  lfacts  and  events 
by  putting  conditions  on  the  words  that  appear  in  them. 


One  can  also  put  conditions  on  the  results  by  specifying 
that  certain  sequences  of  events  must  not  have  occurred. 

The  Analyzer  then  matches  up  output  of  each  rule  with 
the  specified  state,  if  possible,  by  performing  substi¬ 
tutions  on  the  output  that  make  it  reducible,  via  the 
reduction  rules,  to  the  state  specified.  It  may  match 
either  the  entire  state  or  some  subset.  The  input  of  the 
rule  together  with  any  part  of  the  state  then  becomes  a 
new  state  to  be  queried. 

The  way  in  which  the  Analyzer  interprets  rules  allows 
considerable  freedom  in  how  the  matching  is  done.  Vari¬ 
ables  are  local  to  rules,  and,  each  time  a  rule  is  applied, 
a  new  set  of  variables  is  generated.  This  allows  the  An¬ 
alyzer,  for  example,  to  develop  scenarios  involving  mul¬ 
tiple  instantations  of  protocol  rounds,  as  well  scenarios 
in  which  the  same  principal  plays  more  than  one  role. 

2.2  An  Example  Specification 

In  this  section  we  give  the  specification  of  the  modi¬ 
fied  ISO  protocol  in  example  1.2.  The  protocol  con¬ 
sists  of  two  messages.  In  the  first  message,  a  principal 
who  wishes  to  receive  a  message  sends  a  nonce  to  the 
principal  he  wishes  to  receive  a  message  from.  In  the 
next  message  the  sender  sends  a  message,  the  receiver’s 
nonce,  and  his  own  nonce,  signed  and  encrypted.  The 
specification  is  given  below. 

In  the  first  two  transitions,  an  honest  user, 
usertB, honest),  sends  a  request  for  a  message  to 
user(A,Y)  ,  who  may  or  may  not  be  honest.  In  the 
first,  user(B, honest)  chooses  user(A,Y);  in  the  second, 
he  sends  the  request. 

/*user(B, honest)  chooses  sender  of  message*/ 

rule(l) 

If: 

count(user(B, honest) )  =  [M]  , 
then: 

count(user(B, honest) )  =  [s(M)], 

If act (user (B , honest ) , M,recwho , s (M) )  = 

[user(A, Y)] , 

EVENT : 

event (user (B , honest ) ,M, chosewho , s (M) )  = 

[user(A,Y)] • 

/*user(B, honest)  sends  random  number*/ 

rule(2) 

If: 

count(user(B, honest) )  =  [M]  , 

If act (user (B , honest) ,N,recwho,M)  = 

[user(A, Y)] , 

not(user(A,Y)  =  user(B, honest) ) , 
then: 

count(user(B, honest) )  =  [s(M)], 
intruderlearns ( [rand(user(B, honest) ,M)]  ) , 

If act (user (B , honest) ,N,recsendsnonce,s(M) )  = 
[rand(user(B, honest) ,M)] , 

EVENT : 

event (user (B , honest ) ,N,requestedmessage , s (M) ) 

=  [user(A,Y) ,rand(user(B, honest) ,M)] . 


In  the  third  transition,  user(A,  honest)  recieves  a  re¬ 
quest  for  a  message  from  user(B,X),  who  may  or  may 
not  be  honest.  He  sends  an  encrypted,  signed,  message 
to  user(B,X),  including  the  token  that  was  sent.  He 
checks  that  the  length  of  the  word  is  1  (since  this  unit 
length  is  the  length  specified  for  these  random  num¬ 
bers  in  the  later  part  of  the  specification)  and  he  also 
checks  that  user(B,X)  is  not  the  same  as  user(A, honest) 
(since  if  that  were  the  case  the  use  of  this  protocol  and 
the  cancellation  properties  of  public-key  cryptography 
would  result  in  an  unsigned,  unencrypted  message  be¬ 
ing  sent.  He  sends  an  encrypted,  signed,  message  to 
user(B,X),  including  the  token  that  was  sent. 

/*User  A  sends  out  signed  message  with,  random 
number  attached*/ 

rule (3) 

If: 

count (user (A, honest) )  =  [M] , 
intruderknows (  [user(B,X) ,W1] ) , 
length(Wl)  =  1, 

not(user(B,X)  =  user(A, honest) ) , 
then: 

count (user (A, honest) )  =  [s(M)], 
intruderlearns ( [rand(user(A, honest) ,M) , 

Wl,user(B,X) > 
pke(pubkey(user(B,X)) > 

pke(privkey (user (A, honest) ) , 

(rand (user (A, honest) ,M) , 

Wl,user(B,X) > 

mess (user (A, honest ) , M) ) ) )] ) , 

EVENT : 

event (user (A, honest ) ,N, sentsignedmess , s (M) )  = 
[rand (user (A, honest) ,M) ,Wl,user(B,X) > 
mess (user (A, honest) , M)] . 

In  the  next  two  transitions,  user(B, honest)  receives  the 
message  and  checks  it.  If  it  passes  the  tests,  he  accepts 
it  as  coming  from  user(A,Y). 

/*User  B  receives  message  and  verifies  it*/ 

rule (4) 

If: 

count (user (B , honest ) )  =  [R] , 
intruderknows ( [Tl,Wl,user(B, honest) ,Mes] ) , 
lfact(user(B, honest) ,M,recwho,R)  = 

[user(A,Y)] , 

lfact(user(B, honest) ,M,recsendsnonce,R)  = 

[Wl]  , 

then: 

count (user (B , honest ) )  =  [s(R)], 

If act (user (B , honest ) ,M,recmessage , s (R) )  = 

[tail (tail (tail ( 
pke(pubkey (user (A, honest) ) , 
pke(privkey(user(B, honest)) , 
Mes)))))], 

If act (user (B , honest ) ,M, checkaddress , s (R) )  = 
[id_check (head (tail (tail ( 

pke(pubkey (user (A, honest) ) , 
pke(privkey(user(B, honest) ) , 


Mes) ) ) ) ) , 
user(B, honest) )] , 

If act (user (B , honest ) ,M, checknonce , s (R) )  = 
[id_check(head(tail( 
pke(pubkey(user(A, honest) ) , 
pke(privkey (user (B , honest ) ) ,Mes) ) ) ) , 
Wl)]  , 

EVENT : 

event (user (B , honest ) ,M,recsignedmess , s (R) )  = 
[Mes]  . 

In  the  above  rule,  “head”  is  used  to  denote  the  first 
element  of  a  list,  and  “tail”  denotes  what  is  left  af¬ 
ter  the  first  element  is  removed.  Thus,  for  example, 
head(tail((a,b,c)))  =  b. 

/*User  B  accepts  message  if  check  succeeds*/ 

rule(5) 

If: 

count(user(B, honest) )  =  [R]  , 

If act (user (B , honest) ,M,recwho,R)  = 

[user(A, Y)] , 

If act (user (B , honest) ,M,recsendsnonce,R)  = 
[Nonce] , 

If act (user (B , honest) ,M, checkaddress ,R)  = 

[ok]  , 

If act (user (B , honest) ,M, checknonce, R)  =  [ok], 
lfact(user(B, honest) ,M,recmessage,R)  =  [SI], 
then: 

count(user(B, honest) )  =  [s(R)], 

If act (user (B , honest ) ,M,recwho , s (R) )  =  [  ], 

If act (user (B , honest ) ,M,recmessage , s (R) )  = 

[  ], 

If act (user (B , honest) ,M,recsendsnonce,s(R) )  = 

[  ], 

If act (user (B , honest ) , M, accept , s (R) )  = 
[user(A,Y) ,S1] , 

EVENT : 

event (user (B , honest ) , M, acceptmess , s (R) )  = 
[user(A,Y) ,S1] . 

The  remainder  of  the  specification  describes  the  way 
words  are  generated  and  operations  the  intruder  can 
perform.  They  are  listed  below.  The  functions  symbol 
specification  describes  the  function  symbol  pke  desig¬ 
nating  the  public  key  encryption  function.  The  atom 
specification  describes  the  various  basic  words  produced 
by  the  system  such  as  user  names  and  private  and  public 
keys.  Finally,  the  reduction  rule  section  describes  the 
various  reduction  rules  that  operate:  in  this  case,  we 
make  the  assumption  that  encryption  with  correspond¬ 
ing  public  and  private  keys  cancels  out. 

f sdl :pke(X, Y) : length (X)  =  1: 

length(pke(X, Y) )  =  length(Y) :pen. 

atoml :user(A,X) : 1 : known. 
atom2 : mess (user (A, dishonest) , N) : 1 : known. 
atom3 : mes s (user (A, honest ) , N) : 1 :notknown. 
atom4:privkey(user(A, honest) ) : 1 :notknown. 
atom5 :privkey(user(A, dishonest) ) : 1 :known. 


atom6 :pubkey (user(A,X) : 1 :known. 

atomT :rand(user(A, honest) ,N) : 1 :notknown. 

atom8 : rand (user (A, dishonest ) ,N) : 1 : known. 

rrl:  pke(privkey(X) ,pke(pubkey (X) ,Y))  =>  Y. 
rr2:  pke(pubkey(X) ,pke(privkey (X) ,Y))  =>  Y. 


2.3  Mapping  the  Requirements  to  the 
Specification 

In  this  section  we  describe  how  the  statements  in  re¬ 
quirements  1.6  would  be  mapped  to  the  protocol  so  that 
they  could  be  verified  using  the  Protocol  Analyzer.  We 
also  show  in  detail  how  one  of  the  statements  is  verified 
using  the  Analyzer. 

When  we  present  a  query  to  the  Analyzer,  we  have  sev¬ 
eral  options.  We  can  ask  it  to  find  a  set  of  lfact  values, 
a  set  of  words  the  intruder  knows,  a  sequence  of  events 
that  occurred,  or  some  combination  of  the  above.  We 
can  also  put  conditions  on  the  results  it  finds.  We  can 
require  that  words  have  certains  properties,  and  require 
that  certain  sequences  of  events  do  not  occur. 

We  use  the  Analyzer  to  attempt  to  prove  a  state  is  un¬ 
reachable.  Thus  we  must  translate  each  requirement 
into  a  description  of  an  unreachable  state.  This  is  done 
in  two  parts.  First,  each  requirement  R  is  translated 
into  an  equivalent  requirement  of  the  form  not(i?'). 
Secondly,  the  actions  described  in  the  requirement  are 
translated  into  the  corresponding  event  statement  used 
by  the  Analyzer,  transforming  R'  into  a  state  descrip¬ 
tion  R"  that  can  be  presented  to  the  Analyzer.  The 
Analyzer  is  then  used  to  prove  R"  unreachable.  If  this 
can  be  done,  it  has  been  proved  that  the  requirement 
holds. 

We  begin  by  mapping  action  statements  that  describe 
actions  of  honest  principals  to  event  statements.  Again, 
we  note  that  this  mapping  depends  on  the  context  of  the 
protocol.  We  begin  by  finding  the  point  at  which  we  de¬ 
cided  that  an  honest  user  accepts  a  message  and  map¬ 
ping  the  accept  statement  to  the  corresponding  event 
statement.  Thus  the  action  statement 

accept(«ser(5,  honest),  user(A,  honest),  Mes) 

maps  to  the  event  statement 

event  (user(B,honest),M,acceptmess,Tl)  = 
[user(A, honest), Mes]. 

Likewise,  we  find  the  point  at  which  user(A, honest) 
sent  the  message  to  user(B, honest).  Thus  we  have 
the  action  send(«ser(A,  honest),  user(B,  honest),  Mes) 
mapped  to  the  event  statement 

event  (user  (A ,  honest ) ,  M  ,sentsignedmess ,  Q 1 )  = 
[R,W,user(B,  honest),  Mes] 

and  the  action  request(B,  A,  N)  to  the  event  statement 


event  (user(B, honest),  N,requestedmessage,Q2)  = 
[user(A,honest),Rl]. 

Mapping  intruder  actions  to  the  protocol  specification  is 
trickier,  since  intruder  actions,  which  consist  of  learning 
words,  do  not  map  to  specific  transitions,  but  instead 
to  any  transition  which  can  produce  a  word  of  the  ap¬ 
propriate  form.  However,  we  recall  that,  in  querying 
the  Analyzer,  we  can  ask  it  to  produce  a  state  in  which 
the  intruder  knows  a  word  or  word.  This  corresponds 
to  asking  it  to  find  a  state  in  which  the  intruder  learned 
that  word  in  the  past.  If  all  we  wish  to  prove  is  that 
the  intruder  learned  that  word  in  the  past,  and  we  are 
not  concerned  about  ordering,  then  this  is  sufficient.  In 
most  cases,  we  are  mainly  concerned  with  proving  that 
an  intruder  never  learns  a  word;  for  example,  we  want 
to  prove  that  the  intruder  never  learns  a  key,  not  that 
he  does  not  learn  it  before  or  after  it  is  used.  Thus,  in 
most  cases,  the  way  in  which  the  Analyzer  is  queried 
will  be  sufficient.  In  cases  in  which  it  is  not,  we  sim¬ 
ply  discard  the  output  in  which  the  events  occur  in  the 
wrong  order. 

We  now  show  how  we  would  present  the  various  require¬ 
ments  to  the  Analyzer.  The  Analyzer  is  used  by  specify¬ 
ing  an  insecure  state  and  showing  that  it  is  unreachable, 
so  we  use  the  Analyzer  by  specifying  the  negation  of  the 
requirement  and  showing  that  it  is  unreachable.  We  be¬ 
gin  with  the  requirement 

-i(^accept(«ser(B,  honest),  user(A,  honest),  Mes) 
A^learn (P,  Mes)) 

This  requirement  it  presented  to  the  Analyzer  by  asking 
it  to  find  all  cases  in  which  the  accept  event  occurred 
and  the  word  was  learned. 

The  second  requirement  is 

accept(aser(B,  honest),  user(A,  honest),  Mes,  N)  —>■ 
^(send(aser(A,  honest),  user(B,  honest),  Mes)A 
^request (user(B,  honest),  user(A,  honest),  N)) 

It  says  that,  if  the  accept  event  occurred,  then  some 
sequence  of  events  must  have  occurred.  Thus,  in  order 
to  prove  that  this  requirement  is  satisfied,  we  must  prove 
that  the  state  in  which  the  accept  event  occurred  and 
the  previous  events  did  not  occur.  Thus,  we  ask  it  to 
look  for  the  case  in  which 

event (user (B , honest) ,I,acceptmess,M)  = 

[user(A, honest) ,Mes] 

occurred,  but  the  sequence  of  events 

event (user (B , honest) ,I,requestedmessage,Ml)  = 
[user(A, honest) ,R1] 

event(user(A, honest) ,P,sentsignedmess,Q)  = 
[R,W,user(B, honest) ,Mes] 

did  not  occur. 

The  third  requirement  is 


accept(Mser(S,  honest),  user(A,  honest),  Mes)  —>■ 
-^accept (user(C ,  honest),  user(D,  Y),  Mes) 

It  says  that,  if  the  accept  event  occurred,  then  an  accept 
event  for  the  same  message  did  not  occur  in  the  past.  In 
this  case,  we  ask  the  Analyzer  to  look  for  the  sequence 
of  events 

event(user(C, honest) ,11 ,recsignedmess ,M1)  = 
[user(Al,Y) ,Mes] 

event(user(B, honest) ,M,recsignedmess,M)  = 
[user(A, honest) ,Mes] 

We  now  examine  the  second  requirement  in  detail.  The 
proofs  of  the  other  two  are  similar,  but  more  lengthy. 

Before  we  began  presenting  the  requirements  to  the  An¬ 
alyzer,  we  did  a  syntactic  analysis  in  which  we  proved 
that  a  number  of  trivial  states  were  unreachable.  For 
example,  we  proved  that  certain  words  were  unobtain¬ 
able  under  certain  conditions.  We  also  proved  that  some 
lfacts  were  reachable  only  if  certain  conditions  held.  The 
results  of  this  syntactic  analysis  were  then  fed  into  the 
Analyzer,  which  automatically  checked  for  these  condi¬ 
tions  every  time  it  produced  a  solution.  If  the  condi¬ 
tions  were  not  satisfied  it  either  rejected  the  solution, 
or,  if  some  more  specific  case  of  the  solution  satisfied 
the  conditions,  substituted  the  more  specific  case  for 
the  general  one. 

We  began  by  asking  for  a  complete  description  of  all 
states  in  which  the  accept  event  occurred  but  the  cor¬ 
responding  send  and  request  events  did  not  occur.  A 
transcript  follows.  User  input  is  preceded  by  “ — 

?-  begin. 

Give  the  number  of  the  parent  solution, 
if  any . 


What  words  is  the  intruder  looking  for? 

I  : 

What  state  variable  values  is  the  intruder 
looking  for? 

I  : 

List  the  sequence  of  events  that  you  want 
to  have  occurred. 

|:  event(user(B, honest) ,I,acceptmess,M)  = 
[user(A, honest) ,Mes] 

I  : 

What  conditions  do  you  want  to  put 
on  all  of  these? 


List  the  sequences  of  events  that  you 
don’t  want  to  have  occurred. 

Enter  a  list 

|:  event(user(B, honest) ,1, 

requestedmessage,Ml)  = 

[user(A, honest) ,R] 


I:  event(user(A, honest) ,P, sentsignedmess, Q)  = 
[Rl,Wl,user(B, honest) ,Mes] 


Enter  a  list 


One  solution  is  produced: 

Solution  number  1 

The  events  that  occurred  are 

R1  =  event (user (_10416 , honest) , [_10418]  , 
acceptmess , s (_10421) )  = 
[user (_10425 , honest) ,_10427] . 

The  lists  of  events  to  avoid  are 

HI  =  event (user (_10416 , honest) , [_10418] , 
requestedmessage , _10654)  = 
[user (_10425 , honest) ,_10666] . 

H2  =  event (user (_10425 , honest) , [_10679] , 
sentsignedmess , _10674)  = 

[_ 10681 10683 , user (_ 10416 , honest) , 
_10427] . 

Input  state  variables  are: 

51  =  count (user (_10416 , honest) )  =  _10421. 

52  =  If act (user (_10416 , honest) , [_10418] , 

recwho,_10421)  = 
[user (_10425 , honest)] . 

53  =  If act (user (_10416 , honest) , [_10418]  , 

recsendsnonce,_10421)  = 
[rand(user(_10416, honest) ,_10476)] . 

54  =  If act (user (_10416 , honest) , [_10418] , 

checkaddress,_10421)  =  [ok]. 

55  =  If act (user (_10416 , honest) , [_10418] , 

checknonce,_10421)  =  [ok]. 

56  =  If act (user (_10416 , honest) , [_10418] , 

recmessage,_10421)  =  [_10427] . 


Rule  number  5  was  used. 

We  try  to  find  out  if  this  state  is  reachable  by  asking  the 
Analyzer  how  to  find  the  state  in  which  the  the  lfacts 
S2,  S4,  S5,  and  S6  hold.  The  Analyzer  attempts  to 
match  every  subset  of  these  lfacts.  It  turns  up  only  one 
solution,  the  following,  matching  S4,  S5,  and  S6.  S2  is 
thus  required  to  be  part  of  the  intput  state. 

Solution  number  1.1 

The  events  that  will  occur  are: 

FI  =  event (user (_4251 , honest) , [_4253] , 

acceptmess , s (s (_4258) ) )  = 
[user (_4262 , honest) ,_4264] . 

The  events  that  occurred  are 

R1  =  event (user (_4251 , honest) , [_4253] , 

recsignedmess , s (_4258) )  = 
[user (_4262 , honest) , 
pke(pubkey(user(_4251 , honest) ) , 


pke(privkey(user(_4262, honest) ) , 
(_4307 , 

rand(user(_4251 , honest) ,_4314) , 
user (_4251 , honest ) , _4264) ) )]  . 

The  lists  of  events  to  avoid  are 

HI  =  event(user(_4251, honest) , [_4253] , 

requestedmessage , _4751)  = 
[user(_4262, honest) ,_4763] . 

H2  =  event(user(_4262, honest) , [_4776] , 

sentsignedmess, _4771)  = 
[_4778 , _4780 ,user (_4251 , honest ) , 

_4264] . 

Input  words  are : 

W1  =  _4326 

W2  =  rand(user(_4251, honest) ,_4314) 

W3  =  user(_4251, honest) 

W4  =  pke(pubkey (user (_4251, honest) ) , 

pke(privkey(user(_4262, honest) ) , 

(_4307 , 

rand(user(_4251 , honest) ,_4314) , 
user (_4251 , honest ) , _4264) ) ) 

Input  state  variables  are: 

51  =  count (user (_4251 , honest))  =  _4258. 

52  =  lfact(user(_4251, honest) , [_4253] , 

recwho,_4258)  = 
[user(_4262, honest)]  . 

53  =  lfact(user(_4251, honest) , [_4253] , 

recsendsnonce , _4258)  = 
[rand (user (_4251 , honest) ,_4314)] . 
States  found  are: 

D1  =  lfact(user(_4251, honest) , [_4253] , 

recmessage , s (_4258) )  = 

[_4264] . 

D2  =  lfact(user(_4251, honest) ,  [_4253] , 

checkaddress , s (_4258) )  =  [ok]. 

D3  =  lfact(user(_4251, honest) , [_4253] , 

checknonce , s (_4258) )  =  [ok]. 

We  now  ask  the  Analyzer  how  to  find  the  state  in  which 
the  intruder  knows  W4  and  lfacts  S2  and  S3  hold.  In 
this  case  we  get  two  results,  each  matching  W4  and 
requiring  S2  and  S3  to  be  part  of  the  input  state.  Note 
that  the  second  solution  requires  the  intruder’s  use  of 
the  public-key  encryption  function. 

Solution  number  1.1.1 

The  events  that  will  occur  are: 

FI  =  event(user(_10036, honest) ,  [_10038] , 

recsignedmess , s (_10043) )  = 
[user(_10047, honest) , 
pke(pubkey(user(_10036, honest) ) , 
pke(privkey(user(_10047, honest) ) , 
(rand(user(_10047, honest) ,_10053) , 
rand(user(_10036, honest) ,_10109) , 
user(_10036, honest) , 
mess (user (_ 10047 , honest ) 10053) ) ) )] . 

F2  =  event(user(_10036, honest) , [_10038] , 


acceptmess , s (s (_10043) ) )  = 
[user (_10047 , honest) , 
mess (user (_10047 , honest) ,_10053)] . 

The  events  that  occurred  are 

R1  =  event(user(_10047, honest) ,  [_10138] , 

sentsignedmess , s (_10053) )  = 
[rand(user(_10047, honest) ,_10053) , 
rand(user(_10036, honest) ,_10109) , 
user(_10036, honest) , 
mess (user (_10047 , honest) ,_10053)] . 

The  lists  of  events  to  avoid  are 

HI  =  event(user(_10036, honest) ,  [_10038] , 

requestedmessage , _10452)  = 
[user (_10047 , honest) ,_10464] . 

Input  words  are : 

W1  =  user(_10036, honest) 

W2  =  rand(user(_10036, honest) ,_10109) 

Input  state  variables  are: 

51  =  count (user (_10047 , honest))  =  _10053. 

52  =  lfact(user(_10036, honest) , [_10038] , 

recwho , _10043)  = 
[user (_10047 , honest)] . 

53  =  lfact(user(_10036, honest) , [_10038] , 

recsendsnonce , _10043)  = 
[rand(user(_10036, honest) ,_10109)] . 

Words  found  are: 

El  =  pke(pubkey(user(_10036, honest)) , 

pke(privkey(user(_10047, honest) ) , 
(rand(user(_10047, honest) ,_10053) , 
rand(user(_10036, honest) ,_10109) , 
user(_10036, honest) , 
mess (user (_ 10047 , honest ) 10053) ) ) ) 
Rule  number  3  was  used. 

Solution  number  1.1.2 

The  events  that  will  occur  are: 

FI  =  event(user(_9440, honest) , [_9442] , 

recsignedmess , s (_9447) )  = 
[user(_9451 , honest) , 
pke(pubkey(user(_9440, honest) ) , 
pke(privkey(user(_9451, honest) ) , 
(_9494 , 

rand(user(_9440, honest) ,_9501) , 
user(_9440, honest) ,_9453) ) )]  . 

F2  =  event(user(_9440, honest) , [_9442] , 

acceptmess , s (s (_9447) ) )  = 
[user(_9451, honest) ,_9453] . 

The  events  that  occurred  are 

R1  =  event(pen, [_9521] ,pke,s(_9521))  = 
[pubkey (user (_9440 , honest) ) , 
pke(privkey(user(_9451, honest) ) , 
(_9494 , 

rand(user(_9440, honest) ,_9501) , 
user(_9440, honest) ,_9453))] . 

The  lists  of  events  to  avoid  are 

HI  =  event(user(_9440, honest) , [_9442] , 


requestedmessage , _9773)  = 
[user(_9451 , honest) ,_9785] . 

H2  =  event(user(_9451, honest) , [_9798] , 

sentsignedmess , _9793)  = 
[_9800 , _9802 , user (_9440 , honest ) , 

_9453] . 

Input  words  are : 

W1  =  pubkey(user(_9440, honest) ) 

W2  =  pke(privkey(user(_9451, honest) ) , 

(_9494 , 

rand(user(_9440, honest) ,_9501) , 
user(_9440, honest) ,_9453)) 

Input  state  variables  are: 

51  =  count (pen)  =  _9521. 

52  =  lfact(user(_9440, honest) , [_9442] , 

recwho , _9447)  = 
[user(_9451 , honest)] . 

53  =  lfact(user(_9440, honest) , [_9442] , 

recsendsnonce , _9447)  = 
[rand(user(_9440, honest) ,_9501)] . 

Words  found  are: 

El  =  pke (pubkey (user (_9440, honest)) , 

pke(privkey (user (_9451 , honest) ) , 
(_9494 , 

rand(user(_9440, honest) ,_9501) , 
user (_9440 , honest ) ,_9453) ) ) 

Rule  number  301  was  used. 

Notice  that,  in  Solution  1.1.1,  the  second  event  in  our 
series  of  undesirable  events  has  occurred.  When  we  ask 
the  Analyzer  how  to  find  lfacts  S2  and  S3  in  Solution 
1.1.1,  it  finds  that  the  only  way  that  this  can  occur 
is  if  the  request  event  occurs.  This  is  the  third  and 
last  undesirable  event  in  the  series,  and  so  it  rejects  the 
solution  and  declares  the  state  unreachable. 

In  Solution  1.1.2,  the  Analyzer  used  the  fact  that  the 
word  W4  was  of  the  form 

pke(pubkey (user (_9440, honest) ) , 

pke(privkey (user (_9451 , honest ) ) , 

(_9494 , 

rand(user(_9440, honest) ,_9501) , 
user (_9440 , honest ) , _9453) ) ) 

to  prove  that  the  word  was  obtainable  if 

W1  =  pubkey(user(_9440, honest) ) 

and 

W2  =  pke (privkey (user (_9451 , honest )) , 

(_9494 , 

rand(user(_9440, honest) ,_9501) , 
user(_9440, honest) ,_9453) ) 

can  be  found  by  the  intruder.  All  public  keys  are  as¬ 
sumed  to  be  generally  known.  Thus  we  attempt  to  de¬ 
termine  whether  or  not  the  intruder  can  find  W2.  The 


Analyzer  finds  several  solutions,  but  in  our  previous  syn¬ 
tactic  analysis  we  proved  them  unreachable.  Thus  the 
Analyzer  judges  the  word  W2  to  be  unobtainable  by  the 
intruder,  and  says  that  the  state  is  unreachable. 

We  have  now  followed  all  paths  to  the  end  and  proved 
that  each  one  begins  in  an  unreachable  state.  Thus  we 
have  proved  the  original  state  we  specified  unreachable, 
and  hence  that  the  requirement  is  satisfied. 

3  Conclusions 

In  this  paper  we  have  presented  a  formal  language  for 
specifying  and  reasoning  about  cryptographic  protocol 
requirements.  We  have  given  examples  of  simple  sets  of 
requirements  in  that  language.  We  have  looked  at  two 
versions  of  a  protocol  that  might  meet  those  require¬ 
ments  and  shown  how  to  specify  them  in  the  language 
of  the  NRL  Protocol  Analyzer.  We  have  also  shown 
how  to  map  one  of  our  sets  of  formal  requirements  to 
the  language  of  the  NRL  Protocol  Analyzer  and  used 
the  Analyzer  to  show  that  one  version  of  the  protocol 
meets  those  requirements. 

We  regard  the  applications  in  this  paper  as  very  elemen¬ 
tary  and  primarily  for  illustrative  purposes.  We  have 
begun  work  on  more  substantive  and  more  commonly 
applicable  requirements.  In  particular  we  have  specified 
requirements  for  various  types  of  two  party  key  distribu¬ 
tion  protocols,  including  general  requirements  covering 
public  or  shared  key  protocols  and  requirements  for  pro¬ 
tocols  using  Difhe-Hellman  type  key  exchange.  Interest¬ 
ingly,  the  reason  we  cannot  cover  all  of  the  above  with 
a  general  complete  set  of  requirements  is  only  because 
the  session  key  is  not  produced  from  a  single  source  in 
Difhe-Hellman  schemes.  We  have  also  begun  to  specify 
requirements  for  resource  sharing  of  the  kind  found  in 
[BM90].  We  expect  to  find  still  more  applications  for 
our  language  and  technique  in  the  future. 
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